bpo-43224: Implement substitution of unpacked TypeVarTuple#31800
bpo-43224: Implement substitution of unpacked TypeVarTuple#31800serhiy-storchaka merged 5 commits intopython:mainfrom
Conversation
serhiy-storchaka
requested review from
Fidget-Spinner,
JelleZijlstra and
gvanrossum
as code owners
serhiy-storchaka
force-pushed
the
typevartuple-subst
branch
from
da60f24 to
4fab260
Compare
Lib/typing.py
Outdated
| raise NotImplementedError( | ||
| "Type substitution for TypeVarTuples is not yet implemented" | ||
| ) | ||
| if len(self.__parameters__) == 1 and isinstance(self.__parameters__[0], TypeVarTuple): |
There was a problem hiding this comment.
I'm not sure it's sufficient to only check for the case where len(self.__parameters__) == 1 - we could have e.g.:
T1 = TypeVar('T1')
T2 = TypeVar('T2')
Ts = TypeVarTuple('Ts')
class A(Generic[T1, T2, Unpack[Ts]]): pass
B = A[int, T2, Unpack[Ts]]
C = B[str, float]
print(C)There, B.__parameters__ is (T2, Ts), causing a TypeError later on in the code.
There was a problem hiding this comment.
You are right. The previous code only worked with existing tests. New code adds tests for generics with multiple type variables.
|
Thanks for looking into this! |
|
Woah, I'm not sure merging this was a good idea. We discussed this extensively in #31021 (review) and decided against implementing it this way. There are too many edge cases (e.g. the merged implementation will happily assign an unpacked arbitrary-length tuple such as I'd strongly prefer this merge to be reversed in favour of #31804 and/or further discussion on what the right approach is. |
|
I think that Workaround can be used in cases where this does not work. |
|
If you're adamant about keeping this implementation, I don't feel happy about it, but I don't want this to become a blocker for us. I'll submit a new PR with extra test cases so we can be more confident we've covered the edge cases. |
4 participants
https://bugs.python.org/issue43224